Access requests with cache intentions

ABSTRACT

A lease system is described herein that allows clients to request a lease to a remote file, wherein the lease permits access to the file across multiple applications using multiple handles without extra round trips to a server. When multiple applications on the same client (or multiple components of the same application) request access to the same file, the client specifies the same lease identifier to the server for each open request or may handle the request from the cache based on the existing lease. Because the server identifies the client&#39;s cache at the client level rather than the individual file request level, the client receives fewer break notifications and is able to cache remote files in more circumstances. Thus, by providing the ability to cache data in more circumstances common with modern applications, the lease system reduces bandwidth, improves server scalability, and provides faster access to data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application and claims priority toU.S. Pat. No. 8,732,202, issued May 20, 2014, entitled “ACCESS REQUESTSWITH CACHE INTENTIONS” which is a continuation and claims priority toU.S. Pat. No. 8,458,216, issued Jun. 4, 2013, entitled “CLIENT-BASEDCACHING OF REMOTE FILES” which is a divisional and claims priority toU.S. Pat. No. 8,185,566, issued May 22, 2012, entitled “CLIENT-BASEDCACHING OF REMOTE FILES” which applications are incorporated byreference in their entirety.

BACKGROUND

In a client-server environment, clients often cache data that the serverowns and manages. The client stores a copy of data from the serverlocally on the client (e.g., in random access memory (RAM), a page file,a local hard disk, or a flash memory device). The client can access andmodify the cached data locally without communicating across a network orother communication channel for accessing the data remotely at theserver. Because network access is much slower than local access,accessing data locally is more efficient and reduces the burden upon theserver so that the server can handle more requests. Local caching mayhave many benefits. For example, local caching allows the client tocombine multiple write operations on the same region of a file into onewrite operation across the network. In addition, for read operations theclient does not need to request data from the server for each operationif applications read the data multiple times. Caching improves theresponse time of applications because the applications do not wait forthe client to send data across the network to the server upon everyrequest.

One consideration when a server allows multiple clients to access andcache data is ensuring that the clients do not perform conflictingactions on locally cached copies of the data. For example, if one clientwrites new data to its local cache and a second client reads data fromits local cache, the second client will be unaware of the first client'schanges without mechanisms on the server to ensure cache coherency. Somenetwork protocols provide a cache coherency mechanism whereby clientsinform the server of the manner in which the client will use and cachethe data (client intent). For example, a client may cache only reads,only writes, both reads and writes, and so forth. Clients may also havethe ability to cache file handles so that applications can reuse thesame handle for later requests to open the same file.

In SMB 2, the mechanism for performing this type of cache coherency iscalled an opportunistic lock (oplock). A client opportunisticallyrequests the type of access that it wants to a file and the serverconditionally grants or denies access. Even if the server grants access,the server may later break the lock (called a break) by sending theclient a notification that another client has requested conflictingaccess. In the example described above, if the first client obtained awrite-based oplock to a file, the second client's request to obtain aread-based oplock would fail, and the second client would thereby knowthat the locally cached data could be stale so that the second clientwill retrieve the newest data from the server. Using knowledge of theclients that are accessing a particular file and the intent expressed byeach client, the server can manage access to the file so that eachclient stays consistent. For example, the server may temporarily cause anew client to wait for an existing client (who is caching server data)to flush cached data (e.g., sending cached, modified data back from theclient to the server) and cause the data on the server to be consistent,before allowing the new client to access the data.

Unfortunately, the existing oplock semantics were designed 20 years agowhen application behavior was significantly more simple and predictable.On modern operating systems, developers build applications over multiplelayers of abstraction, and often end up performing redundant file systemoperations. For example, several different components within the sameapplication may open the same file, each with different intentions forusing the file (e.g., some reading and some writing). The cost of theseredundant operations may be acceptable when the file is stored locally,but when an application accesses the file over a network the cost canquickly add up, resulting in unresponsiveness observed by an end user ornetwork chattiness observed by a network administrator. The existingoplock model allows clients to cache data under some circumstances, butmodern applications operate outside of the caching circumstancesanticipated by the SMB 2 designers in many cases, with the result thatthe client is often unable to locally cache data or file handles.

In addition, modern computing systems run many more applicationssimultaneously than in the past, and several applications may attempt toaccess the same remote file at the same time. SMB 2 and other protocolstypically treat each access request as coming from a separate client,even if the requests come from different applications on the sameclient. When multiple applications are running on the same client, thelikelihood is high that a user is using the applications to perform asingle task that involves a particular data file. As an example, a shell(e.g., computer user interface) may be trying to query icon attributesat the same time that a document application is trying to open and savea document. This can break an oplock related to the document so that theclient determines the cache to no longer be valid. This makes read/writeoperations slower because they have to go across the network. As anotherexample, the shell may try to render a preview of a document in a smarticon and at the same time, a search indexer may try to index thecontent. When two applications on the same client decide to access thefile simultaneously, the server could revoke the ability of that clientto cache data. These situations further reduce the opportunity forcaching using existing caching semantics.

SMB2 oplocks have several limitations. First, oplocks are tied to anopen file handle. When a client opens a file, the client requests aparticular oplock and receives the lock along with a handle to the filefrom the server. This means that a client can maintain an oplock only ifit has an open handle to a file. Second, the protocol does not allowclients to cache writes and open handles if there is more than one openhandle to the file. As noted above, most modern applications openmultiple handles to the same file, effectively resulting in a loss ofwrite caching and handle caching. For the same reason, multiple clientscannot cache open file handles. Finally, if multiple applications areread-caching data, the client cannot maintain the read-cache after theapplication that initially read the data closes the handle to the file.This is because as noted above the oplock is associated with the handlewith which it was opened.

SUMMARY

A lease system is described herein that allows clients to request alease to a remote file, wherein the lease permits access to the fileacross multiple applications using multiple handles without extra roundtrips to a server. A client initially specifies a file and requests alease from the server. The server determines whether to grant a leasebased on other client requests related to the specified file. If theserver grants the lease, the client receives a lease identifier andallowable caching of the file. When a server receives a conflictingrequest to access the file, the server sends the client a lease breaknotification. When multiple applications on the same client (or multiplecomponents of the same application) request access to the same file, theclient specifies the same lease identifier to the server or may handlethe request from the cache based on the existing lease. Because theserver identifies the client's cache at the client level rather than theindividual file request level, the client receives fewer breaknotifications and is able to cache remote files in more circumstances.Thus, by providing the ability to cache data in more circumstancescommon with modern applications, the lease system reduces bandwidth,improves server scalability, and provides faster access to data.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that illustrates components of the leasesystem at a typical client, in one embodiment.

FIG. 2 is a block diagram that illustrates a typical operatingenvironment of the lease system, in one embodiment.

FIG. 3 is a flow diagram that illustrates the processing of the leaserequest component, in one embodiment.

FIG. 4 is a flow diagram that illustrates the processing of the breakhandling component of the lease system, in one embodiment.

DETAILED DESCRIPTION

A lease system is described herein that allows clients to request alease to a remote file, wherein the lease permits access to the fileacross multiple applications using multiple handles. A client initiallyspecifies a file and requests a lease from the server. The client maypass an identifier (e.g., a globally unique identifier (GUID) or key) todistinguish the lease from other leases, or the server may provide anidentifier when the server responds to the lease request. The serverdetermines whether to grant a lease based on other client requestsrelated to the specified file. If the server grants the lease, theclient has an identifier and certain allowable uses of the file. Forexample, when the client requests a lease the client may also requestread access, write access, and/or handle caching access. When a serverreceives a conflicting request to access the file, the server sends theclient a revocation or downgrade of the lease. For example, if theserver receives a request from another client to read file data and theexisting client has read/write access to the file, the server may revokethe existing client's lease or downgrade the lease by removing writeaccess. When multiple applications on the same client (or multiplecomponents of the same application) request access to the same file, theclient specifies the same lease to the server or may handle the requestfrom the cache based on the existing lease. As applications open andclose files, the lease remains because the lease is not associated withany particular handle to the file. Thus, by providing the ability tocache data in more circumstances common with modern applications, thelease system reduces bandwidth, improves server scalability, andprovides faster access to data.

System and Environment

FIG. 1 is a block diagram that illustrates components of the leasesystem at a typical client, in one embodiment. The lease system 100includes an application interface 110, a lease request component 120, acommunication component 130, a cache component 140, and a break handlingcomponent 150. Each of these components is described in further detailherein.

The application interface 110 provides an interface through whichapplications submit requests to open remote files to the lease system100 and receive file data. Applications may run in user or kernel modeand use an operating system file access interface to open and accessfiles. The application interface 110 receives requests to access remotefiles, uses the lease request component 120 to send open requests toremote servers that include a lease identifier, and caches data receivedfrom the remote servers based on the terms of received leases. In somecases, the application interface 110 may provide file data to anapplication directly from the cache component 140 without additionalcommunication with the remote server. For example, the lease system 100may collapse the open request onto an existing handle as describedfurther herein.

The lease request component 120 sends lease requests to a remote serverand handles received lease responses. A lease response may either grantor deny a lease, and may suggest a lease that is lower than a requestedaccess level based on existing client access to a file. For example, aserver may deny a lease for write caching if there are multiple clientsreading a file, but may grant additional read leases. Thus, the servermay suggest a read lease in response to a request for a write lease.This reduces round trips between the client and server to negotiate anavailable lease state. Based on the lease request, the server candetermine how each client is using a particular file and can informclients (e.g., using break notifications described herein) when oneclient's use of a file is inconsistent with a caching strategy used byother clients.

The communication component 130 transmits requests and receivesresponses over a network that connects one or more clients and servers.The communication component 130 may include network hardware (e.g., anetwork interface card (NIC), switches, routers) and a TCP/IP or otherlow-level networking stack. The SMB2 or other higher-level protocol thatimplements the lease system 100 as described herein communicates usingthe communication component 130 with the other clients and servers.

The cache component 140 caches data at the client based on informationreceived from the server. One purpose of the lease system 100 is toincrease the opportunity to cache data so that the system 100 can servemany file access requests from the cache component 140 rather than fromthe server using a network round trip. The cache component 140 isassociated with a particular lease identifier that the server uses todistinguish one cache provider from another. Requests to open files thatthe cache component 140 will cache use the lease identifier whenrequesting to open files stored on the server. The server compares thelease identifier to previously received lease identifiers and trackseach client so that the server can notify clients of new access to thefile that conflicts with the previous caching strategy.

The break handling component 150 responds to break notificationsreceived from the server. The server sends a break when access (e.g., tocache writes) that the server previously granted is no longer compatiblewith access requests of other clients accessing the same file. Forexample, if a server grants a lease for a first client to write cachedata, and a new client requests to read cache data, then the serversends a break to the first client indicating for the first client tostop caching writes to prevent cache inconsistencies between the firstclient and the new client.

The computing device on which the system is implemented may include acentral processing unit, memory, input devices (e.g., keyboard andpointing devices), output devices (e.g., display devices), and storagedevices (e.g., disk drives). The memory and storage devices arecomputer-readable media that may be encoded with computer-executableinstructions (e.g., software) that implement the system, which means acomputer-readable medium that contains the instructions. In addition,the data structures and message structures may be stored or transmittedvia a data transmission medium, such as a signal on a communicationlink. Various communication links may be used, such as the Internet, alocal area network, a wide area network, a point-to-point dial-upconnection, a cell phone network, and so on.

Embodiments of the system may be implemented in various operatingenvironments that include personal computers, server computers, handheldor laptop devices, multiprocessor systems, microprocessor-based systems,programmable consumer electronics, digital cameras, network PCs,minicomputers, mainframe computers, distributed computing environmentsthat include any of the above systems or devices, and so on. Thecomputer systems may be cell phones, personal digital assistants, smartphones, personal computers, programmable consumer electronics, digitalcameras, and so on.

The system may be described in the general context ofcomputer-executable instructions, such as program modules, executed byone or more computers or other devices. Generally, program modulesinclude routines, programs, objects, components, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Typically, the functionality of the program modules may becombined or distributed as desired in various embodiments.

FIG. 2 is a block diagram that illustrates a typical operatingenvironment of the lease system, in one embodiment. There is shown aclient machine 200 including at least one user-mode application program202 that requests various system functions by calling an API layer 204that provides application programming interfaces (APIs). At the top ofthe broken line 205 is illustrated a client-server interaction and atthe bottom of line 205 a client-client interaction is illustrated. Foraccessing files stored on a remote network server 220, the applicationprogram 202 places file input output (I/O) API calls directed to anetwork resource to an API layer 204. For example, applications canexamine or access resources on remote systems by using a Uniform NamingConvention (UNC) standard with Win32 functions to directly address aremote resource, e.g., via a drive mapped to a network shared folder orthe like.

When an application calls a file I/O API (e.g., a file open or createrequest) with a remote filename such as a UNC name, a file I/O requestis received at an I/O manager 206. To handle the remote name, the I/Omanager 206 calls a name provider 208 to determine which device handlesthe name. In other words, the name provider 208 (e.g., comprising akernel mode driver) determines which network to access when anapplication program 202 uses an I/O API to open a remote file upon acreate request. To determine a device that can handle the given name,the name provider 208 polls (via asynchronous I/O request packets, orIRPs) any redirectors that have previously registered with the nameprovider 208, e.g., the protocol redirector 210. Each redirector thatcan handle the name responds back affirmatively, and if more than oneresponds, the name provider 208 determines from a priority order (e.g.,maintained in at least one system registry key or the like) which onehas precedence to handle the request.

As part of the response to the name provider 208, each redirector thatrecognizes the name indicates how much of the name is handled by thatredirector. For example, if the name is the UNC name\SERVER\SHARE\foo\bar1.doc, the redirector 210 recognizes the name ascapable of being handled, and the server responds by claiming the string“\SERVER\SHARE” as its own. When at least one redirector (e.g., theredirector 210) responds and provides the caching information, the nameprovider 208 driver caches the information in association with theredirector that responded, (if more than one, it caches the informationof the one that takes precedence), whereby further requests beginningwith that string are sent directly to that redirector 210, without thepolling operation. For example, if the redirector 210 comprises an SMBredirector, future SMB requests directed to a network sharecorresponding to a cached string are passed to the redirector 210, whichthen packages those SMB requests into a data structure that can be sentacross the network to that remote SMB server.

In one implementation, the redirector 210 is a kernel mode componentthat provides I/O requests to a remote server 220 via a protocol driver214 (e.g., TDI transport) connected to a communications link 216. Theserver 220 receives the I/O requests at a counterpart protocol driver214, and passes them to a file server 218 and local file system driver222 (e.g., FAT or NTFS) on its local file system files 224. The server220 uses a file system driver that communicates with the server driveron a remote server system. In addition, the server file system driver222 and the file server 218 service work for the connections requestedby client-side redirectors, forwarding them to the appropriate localfile system driver, such as NTFS.

In one embodiment, when accessing files on remote servers 220, forexample, the file server and not the client application program 202requests the opportunistic lock from the remote server 220. Clientapplications directly request opportunistic locks when the oplock isintended for a file on a local file system (as shown on the bottom ofFIG. 2). This is illustrated between client 201 and client 203 below thebroken line 205. The client 201 comprises similar components as client200 above the broken line 205 and in addition comprises a storagecomponent 213. The storage component 213 comprises file system files 215local to the client and accessed via a local driver 217 through the I/Omanager 206 and/or through the API layer 204. When the client requestsan oplock on a local file, the request goes directly to the local filesystem and does not travel over the remote I/O path as indicated in theclient-server interaction above broken line 205, which separates the twodifferent interactions. Other clients connected to the communicationslink 216, for example client 203, therefore also benefit from the oplockmechanisms intended for a file on a local file stream.

Leases

When requesting a lease, a client passes two pieces of information tothe server: a file identifier and a set of requested capabilities. Thefile identifier may include a UNC path or other common mechanism foridentifying a file. The set of requested capabilities may include one ormore flags that correspond to read, write, and handle access or otheraccess capabilities. The client may also pass additional information,such as an identifier for the client that distinguishes the client fromother clients. The identifier can be provided by the protocol, or theserver can use the source address. This allows a client to establishmultiple connections to the server and share leases across eachconnection.

The requested capabilities can be determined in several ways. Typically,the client is opening a file in response to an application request toaccess the file. The client may request only as much access as thecurrent application wants. For example, if the application requests readaccess, then the client may request a read-based lease from the server.In some embodiments, the client may request additional access so that ifthe client receives additional application requests for additionalaccess, the client can handle those requests without an additionalrequest for additional access to the server. For example, the client mayalways request full access to the file, and then listen for the serverto send break notifications indicating that other clients want to accessthe file. When the client receives a break notification, the client mayrequest the lowest access level that will satisfy each application onthe client that is currently accessing the file. This is an efficientapproach when, for example, a large percentage of the time only oneclient accesses a particular file at a time. In the few cases whenmultiple clients do access the same file, each client can negotiate thelevel of access that it needs with the server.

Another piece of information is the lease identifier, which may beprovided by the client or generated by the server. From the server'sperspective, the lease identifier distinguishes one client from another(or more specifically one cache from another). Previously, thisinformation was unavailable to the server, and the server assumed thateach request to access a file came from a different cache provider(e.g., client). Thus, when requests conflicted, the server in most caseshad to issue a break. Using the lease system, the server can determinewhen requests to access the same file come from the same client, and canreduce the number of breaks (e.g., by assuming that requests from thesame client do not cause cache incoherence) so that caching is effectivein more situations.

FIG. 3 is a flow diagram that illustrates the processing of the leaserequest component, in one embodiment. The component is invoked when anapplication requests that a client open a remote file. In block 310, thecomponent receives information from the application indicating the fileto open in an open request. For example, the application may provide aUNC path to a remote file accessible over a network. Continuing in block320, the component determines whether a lease exists for the indicatedfile. For example, the component may look up the UNC path in a table ofleases. The lease provides cache coherency information associated withthe remote file independent of zero or more open handles to the remotefile. Continuing in decision block 330, if the component does not findan existing lease, then the component continues at block 340, else thecomponent continues at block 360. In block 340, the component sends arequest to the server to open the file and request a lease. Thecomponent may generate a lease identifier and send the identifier to theserver with the request. Continuing in block 350, the component receivesa response from the server indicating whether the server granted therequested lease. The component also receives the file data and metadatafor the requested file that the component stores in a local cache forlater use.

In block 360, reached if there was an existing lease, the componentdetermines whether a user associated with a current request is the sameas a user associated with the existing lease, and whether the accessrequested to the file is compatible with the scope of the existinglease. When the user is different, it may be desirable to send therequest to access the file to the server so that the server can enforceany user-specific access control. In decision block 370, if the user andrequested access are the same as the existing lease, then the componentcontinues at block 380, else the component continues at block 390. Inblock 380, the component collapses the current open request onto theexisting lease, and provides requested data from the cache whenavailable. For example, if a new application wants to read from a remotefile that is already open for reading by a first application, then thecomponent may provide the existing handle of the first application tothe new application for accessing the file, without making a round tripto the server. This improves the apparent responsiveness of the newapplication. In block 390, reached when the existing lease isinsufficient for the new application, the component requests a new leasefrom the server to see if caching for the type of access requested bythe new application is compatible with the use of the file by otherclients. After block 390, these steps conclude. When the client receivesthe next request to access a remote file, the component performs thesesteps again.

In some embodiments, the lease system allows write caching if there isexactly one lease on the file. Since multiple handles to the same filefrom the same client use the same lease, the system allows write cachingas long as there are no other clients accessing the file. In this way, asingle client with multiple applications making extensive use of a filecan still cache data so long as no other client requests concurrentaccess to the file. In many cases, only a single client accesses a fileat a time, so this allows the lease system to provide caching in manycommon scenarios. Write caching also permits the client to cachebyte-range locks on the file, since it indicates exclusive access (e.g.,a client does not need to send locks to the server since no one else isaccessing the data stream).

In some embodiments, the lease system allows handle and read cachingwhen multiple clients are reading from the same file. This implies thatclients can continue to cache data and open file handles even after aninitial application has closed the handle or terminated. Read and handlecaching allows the client to hold an open after the application hasclosed its handle. If the application decides to reopen the file, theapplication can find and reuse an existing open (and the data in thecache). The lease also survives the application, and allows additionalapplications on a client to access the file and share the same cache.

In some embodiments, the lease system allows a client to delay closingof file handles using handle caching. The client can also collapse newopen requests to the same file onto an existing open handle, providedthe new open is compatible with the existing opens (e.g., in terms ofaccess requested). The system also allows the client to flow backcollapsed opens to the server when handle caching is revoked by theserver. In other words, over time the client may have severalapplications accessing a file using the same handle, when the clientreceives a server break. When the client receives the break, the clientcan request a new handle for each of the applications or request areduced level of access if the applications are not using as great alevel of access as the original application that opened the handle. Thiscan be viewed as a type of lazy access request that reduces networktraffic between the client and the server by postponing notifications ofa change in access from the client to the server until there is aconflict for a particular file.

Lease Revocation

In some embodiments, the lease system does not revoke or downgradeleases due to an operation on a file handle associated with the samelease. Thus, no matter what a single client is doing, the cache willremain available and coherent. A client may have multiple applicationsaccessing the file or multiple components within a single applicationaccessing the file, but no breaks will occur. In other words, using thelease system the server operates at the granularity of clients ratherthan at the granularity of individual access requests. The client takesresponsibility for requesting the type of lease to satisfy each of itsapplications and requests for a particular file.

In some embodiments, the lease system assigns a duration to leases,after which the leases expire and the server revokes the leases. Forexample, a server may grant a lease with a particular time-to-live(TTL), after which the client can no longer rely on the lease to ensurecache coherency. When a lease expires or is near expiration, the clientmay request a new lease from the server or renew the existing lease sothat the client can continue to access remote files. Lease expirationallows the server to clean up resources associated with leases even whenclients disconnect or are non-responsive to server requests.

A server initiates an oplock break by sending an oplock breaknotification to one or more clients. Depending on the semantics of thebreak, the client may respond with an oplock break acknowledgementrequest. The server will then respond with an oplock breakacknowledgement response. As opposed to the traditional model where theoplock break is associated with an open handle, the new model associatesan oplock break with the lease identifier. Other data that could helpthe client more intelligently flush out open handles and data may alsobe included in the protocol. The client closes any delay-closed andclose-pending opens before acknowledging the oplock break. If the breakindicates a loss of handle caching, then the client will close allexisting (delay closed) opens to the file, including closing the open onwhich the client received the oplock break last if that handle was alsodelay closed.

In some embodiments, when responding to an oplock break notification,the client has the ability to request a higher oplock level than thatindicated in the oplock break notification. However, there is noguarantee that a server can grant the oplock request. In such asituation, the server fails the oplock break acknowledgement requestwith an error so that the client can take appropriate action (e.g.,flush unwritten data) and re-acknowledge.

FIG. 4 is a flow diagram that illustrates the processing of the breakhandling component of the lease system, in one embodiment. The componentis invoked when a server sends a break notification to a client.Typically, the break is the result of a second client attempting toaccess the same file as the original client in a way that conflicts withan existing lease of the original client. The break allows the originalclient to keep its cache coherent by informing the original client ofthe manner in which the second client may use the file. In block 410,the component receives a break request from the server. The breakrequest may include information such as the lease identifier provided bythe client when the client opened the file to which the break applies,the current lease state of the lease held by the client, and the newlease state available to the client. For example, if a new client wantsto read from a remote file, a previous client with a write-caching leasemay receive a break that indicates that write caching is no longeravailable, but read caching is available. Continuing in block 420, thecomponent compares the old lease state to the received new lease state.

Then in block 430, the component flushes any cached data that the clientwill no longer cache or that is no longer valid based on the new leasestate, and closes any delay closed opens. For example, if the client wascaching writes, and the new lease state indicates that write caching isno longer available, then the client flushes pending written data to theserver and stops caching data written to the file by one or moreapplications. Continuing in block 440, the component sends anacknowledgement request to the server, to indicate that the client hashandled the break. The acknowledgement request may request a differentlease scope based on the desired access to the file of applications onthe client. In some embodiments, the client can acknowledge the leasebreak by closing all opens for a given lease instead of sending anexplicit acknowledgement. Continuing in block 450, the componentreceives an acknowledgement response from the server. If the clientrequested a new lease scope, then the received response indicateswhether the server granted the new lease scope. Continuing in block 460,the client handles requests from the cache that are compatible with thenew lease state and sends other requests to the server. After block 460,these steps conclude.

In some embodiments, each handle to the same file from a given clientshares the same lease identifier. In this way, the server treats anyrequest from the client as making use of the same cache. Thus, there isno cache coherency conflict between any use of the file on that client,and the server can avoid sending breaks unless a second client (with adifferent lease identifier) requests access to the file that wouldconflict with the original client's access.

In some embodiments, the lease system provides the same lease identifierfor a file accessed using different names. Clients can access remotefiles through a variety of paths. For example, a particular server mayshare a file through two different shares (e.g.,\\server\share1\file.doc may point to the same file as\\server\share2\file.doc or \\server\share2\folder\file.doc). It may notbe possible for a client to determine that two files accessed throughdifferent paths are the same file. Thus, the lease system may requestthat the server resolve whether two files are the same, and provide thesame lease identifier for accessing both. This allows the client tocache a file under the same lease key even in the presence of namealiasing.

In some embodiments, the lease system provides backwards compatibilitywith older servers and clients. On the client side, the system mayprovide an oplock level in a create request that matches a legacy oplocklevel along with new parameters, such as the lease identifier. The SMB2protocol allows clients to specify an extended create parameter (ECP).If the server is a legacy server, it will ignore the new parameters andgrant the client an oplock of the requested legacy type. The client candetermine by the response type whether the server granted a legacyoplock or a lease based on the client's request. Similarly, a serverthat implements the lease system may continue to provide legacy oplocksto older clients that access files without specifying new parameters,such as the lease identifier. In this way, the system can operate in amixed environment of clients and servers.

In some embodiments, the lease system allows the server to avoid a breakwhen a disconnected client reconnects to the server. In the past, if aclient lost a connection to the server, the client would retry theconnection by opening a new file handle to the server. This caused anyexisting clients to receive a break notification if the requested accessconflicted with that of the existing clients. The lease system providesthe previous lease identifier to the server when the client reconnects.If the server recognizes the lease identifier based on an existinglease, the server can grant the client the same level of oplock that theclient previously held and avoid sending breaks to existing clients.Particularly with the increased use of wireless networks, disconnectingand reconnecting clients have become more common, and this capability ofthe lease system reduces network bandwidth consumption in suchsituations.

Even when a client closes a remote file normally, the server may stillstore the lease information for a period in case the client re-opens thefile. Many application patterns involve an application repeatedlyrunning and accessing the same file, and by maintaining the leaseidentifier and other information, the server reduces the burden ofresponding to such requests.

In some embodiments, the lease system allows a client to collapsesubsequent open request for a file onto an existing open withoutinforming the server of the new request to use the file. For example, ifa new application attempts to open a file that is already open, and theexisting open specified a caching level that is compatible with theexisting lease, then the client can allow the new application to accessthe file using the existing handle or lease. If the new applicationrequest is not compatible with the existing lease, the client mayrequest a different lease from the server that encompasses the level ofaccess requested by each application accessing the file on the client.The client may also take into account the user attempting to access thefile (e.g., not allowing collapsing for different users) to allow theserver to properly enforce access control. For example, one user mayhave access to a file and another may not have access based on serveraccess control lists (ACLs), and the client avoids allowing the userwithout access to access the file via a collapsed open request.

When the lease system collapses handles, there may be some instances inwhich the handles will be un-collapsed and flow back to the server asindividual requests. When a break occurs, the server may benefit fromadditional information about how applications are actually using a filethrough a particular lease. Thus, the client may respond to the break byrequesting a new lease or leases for applications that were previouslysharing one or more collapsed opens. For example, if one application wasreading and writing a file and another was only reading the file, theclient may have collapsed each use onto a single read/write-based lease.If the server sends a break indicating that write caching is no longeravailable, then the client can still request a read-based lease for theread-only application, so that application can continue using cacheddata.

SMB Protocol Changes

The following are specific examples of changes to the SMB2 protocol thatcould support the lease system described herein.

In some embodiments, the client and server advertise capability for theenhanced oplocks used by the lease system via the SMB2 negotiaterequest/response. During this exchange, the client and server canprovide one or more bits describing their capabilities. The lease systemprovides a new bit, SMB2_GLOBAL_CAP_ENHANCED_OPLOCKS, through which theclient and server provide information about their support for the leasesystem. The lease system may also modify the protocol dialect revision(i.e., version number) to indicate support for the lease system.

In some embodiments, clients provide extended information during an openrequest. For example, the lease system may define a new SMB2 createcontext (ECP) to request an enhanced oplock as well as to pass the leaseidentifier to the server. The server can return the granted oplock viathe same ECP. Following is an example data structure for conveying thisinformation:

typedef struct {   GUID LeaseKey;   DWORD LeaseState;   DWORD Flags;  INT64 LeaseDuration; } SMB2_ECP_REQUEST_LEASE,  // Client->Server  SMB2_ECP_GRANTED_LEASE;  // Server->Client

As noted previously, the lease identifier (e.g., LeaseKey GUID above),may be generated by the client, so that the identifier can be used toidentify the client side entity via which a file is cached. Multiplehandles to the same file may share a data structure on the client thatstores the lease identifier used in the create request. These handleswill also thereby have a shared oplock state on the server, andconsequently will not break each other's oplock state. Alternatively oradditionally, the server may generate the lease key based on theclient-ID and the file being opened or other information. This allowsthe server to inform the client that a file opened via two differentnames actually refers to the same file on the server and hence tell theclient to use the same cache even though the path names are different.

In some embodiments, the server provides the enhanced oplock in thecreate response. Although the client may set the LeaseState field in thecreate request to a legacy oplock level so that a server which does notunderstand the enhanced oplocks can still grant a legacy oplock to theclient, the server may ignore this level when the above ECP is used bythe client. Thus, a server that supports the enhanced sets theLeaseState in the create response to a new value,SMB2_OPLOCK_LEVEL_LEASE, that indicates that the server granted anenhanced oplock as described herein.

In some embodiments, when a server initiates a break as describedherein, the server sends the following data structure to the client toinform the client of the break and to allow the client to moreintelligently flush out open handles and data.

typedef struct {   USHORT StructureSize; //sizeof(SMB2_NOTIFY_BREAK_LEASE)   USHORT Reserved;   ULONG Flags;   GUIDLeaseKey;   ULONG CurrentLeaseState; // current oplock level   ULONGNewLeaseState; // new oplock level (subset of current)   ULONGBreakReason; // what caused the break   union {     struct {       ULONGAccessMaskHint; // Used to selectively close       ULONG ShareMaskHint; // cached handles.     } Create;   } Reason; } SMB2_NOTIFY_BREAK_LEASE;

The AccessMaskHint and ShareMaskHint optionally provide a hint to theclient as to what handles to flush out when the server indicatesrevocation of handle caching. The client can also use these flags toretain or give up additional oplock state when acknowledging the break.Upon receiving a break request, the client performs any relevant actions(e.g., flushing cached data), and sends an oplock break acknowledgementrequest. Following is a data structure for the request according to someembodiments of the lease system.

typedef struct {   USHORT StructureSize; // sizeof(SMB2_REQ_ACKNOWLEDGE_BREAK_LEASE)   USHORT Reserved;   ULONG Flags; //downgrade ok, intermediate ack   GUID LeaseKey;   ULONG LeaseState; //New oplock level requested by client   INT64 LeaseDuration; }SMB2_REQ_ACKNOWLEDGE_BREAK_LEASE;

In response, the server determines how to handle the client's requestand sends an acknowledge break response. For example, the client mayhave requested a different lock level based on the break and the serverdetermines whether the new lock level will conflict with other clients'use of the file. Following is a data structure for the responseaccording to some embodiments of the lease system.

typedef struct {   USHORT StructureSize; // sizeof(SMB2_RESP_ACKNOWLEDGE_BREAK_LEASE)   USHORT Reserved;   ULONG Flags;  GUID LeaseKey;   ULONG LeaseState; // New oplock level granted to theclient   INT64 LeaseDuration; // Duration of new lease }SMB2_RESP_ACKNOWLEDGE_BREAK_LEASE;

Oplock break notifications from the server and oplock breakacknowledgement responses from the server can use the same SMB2 commandcode, SMB2_(—)0_COMMAND_OPLOCK_BREAK. The client identifies the type ofresponse by looking at the message ID in the SMB2 header. For an oplockbreak notification the server sets the message ID to SMB2_INVALID_MID.For an oplock break acknowledgement response, the message ID will matchthat of the client's oplock break acknowledgement request. Alternativelyor additionally, the client can use the StructureSize field or otherinformation to distinguish the two responses.

From the foregoing, it will be appreciated that specific embodiments ofthe system have been described herein for purposes of illustration, butthat various modifications may be made without deviating from the spiritand scope of the invention. For example, although extensions to the SMB2protocol have been described, the lease system can be used with othernetwork access protocols. As another example, although accessing fileshas been described, the techniques of the lease system can be applied toother units of data, such as databases (or database entries), multi-fileobjects, and so forth. Accordingly, the invention is not limited exceptas by the appended claims.

We claim:
 1. A method for sending a lease break notification by aserver, wherein the lease break notification breaks a lease at a leaseaccess level, the method for sending the lease break notificationcomprising: receiving a first request for access to a file from a firstclient, the first request for access including a first access level anda first lease identifier that identifies the first client; granting afirst lease to the first client at the first access level, whereingranting the first lease includes sending a lease response that includesinformation to be cached at the client from the remote file managed bythe server; receiving a second request for access to the file from thefirst client, the second request for access including a second accesslevel and the first lease identifier, wherein the second access level ishigher than the first access level; collapsing the second request intothe first lease based on the common first lease identifier in the firstrequest and the second request, wherein the first lease is upgraded tothe second access level; receiving a third request for access to thefile from a second client, the third request for access including thefirst access level and a second lease identifier that identifies thesecond client; granting a second lease to the second client at the firstaccess level; and sending the lease break notification to the firstclient, wherein the lease break notification breaks the first lease, andwherein the lease break notification includes the first access level forthe second lease.
 2. The method of claim 1, wherein the lease accesslevel is comprised of: read access, write access, and read and writeaccess.
 3. The method of claim 1, wherein upon granting the first lease,the server sends the first client file data and metadata correspondingto the file.
 4. The method of claim 1, wherein the lease breaknotification includes the first lease identifier.
 5. The method of claim1, further comprising: receiving, by the server, an acknowledgement fromthe first client that the lease has been broken.
 6. The method of claim1, wherein collapsing further comprises comparing the first client to alist of clients in an access control list.
 7. The method of claim 6further comprising confirming that the first client is allowed access tothe file at the second access level.
 8. A computer system comprising: aprocessor; and a memory communicatively coupled to the processor, thememory having computer-executable instructions that when executed by theprocessor, provide a method for sending a lease break notification by aserver, wherein the lease break notification breaks a lease at a leaseaccess level, the method for sending the lease break notificationcomprising: receiving a first request for access to a file from a firstclient, the first request for access including a first access level anda first lease identifier that identifies the first client; granting afirst lease to the first client at the first access level, whereingranting the first lease includes sending a lease response that includesinformation to be cached at the client from the remote file managed bythe server; receiving a second request for access to the file from thefirst client, the second request for access including a second accesslevel and the first lease identifier, wherein the second access level ishigher than the first access level; collapsing the second request intothe first lease based on the common first lease identifier in the firstrequest and the second request, wherein the first lease is upgraded tothe second access level; receiving a third request for access to thefile from a second client, the third request for access including thefirst access level and a second lease identifier that identifies thesecond client; granting a second lease to the second client at the firstaccess level; and sending the lease break notification to the firstclient, wherein the lease break notification breaks the first lease, andwherein the lease break notification includes the first access level forthe second lease.
 9. The computer system of claim 8, wherein the leaseaccess level is comprised of: read access, write access, and read andwrite access.
 10. The computer system of claim 8, wherein upon grantingthe first lease, the server sends the first client file data andmetadata corresponding to the file.
 11. The computer system of claim 8,wherein the lease break notification includes the first leaseidentifier.
 12. The computer system of claim 8, further comprising:receiving, by the server, an acknowledgement from the first client thatthe lease has been broken.
 13. The computer system of claim 8, whereincollapsing further comprises comparing the first client to a list ofclients in an access control list.
 14. The computer system of claim 13further comprising confirming that the first client is allowed access tothe file at the second access level.
 15. One or more computer storagemedia having computer-executable components that upon execution performa method for sending a lease break notification by a server, wherein thelease break notification breaks a lease at a lease access level, themethod for sending the lease break notification comprising: receiving afirst request for access to a file from a first client, the firstrequest for access including a first access level and a first leaseidentifier that identifies the first client; granting a first lease tothe first client at the first access level, wherein granting the firstlease includes sending a lease response that includes information to becached at the client from the remote file managed by the server;receiving a second request for access to the file from the first client,the second request for access including a second access level and thefirst lease identifier, wherein the second access level is higher thanthe first access level; collapsing the second request into the firstlease based on the common first lease identifier in the first requestand the second request, wherein the first lease is upgraded to thesecond access level; receiving a third request for access to the filefrom a second client, the third request for access including the firstaccess level and a second lease identifier that identifies the secondclient; granting a second lease to the second client at the first accesslevel; and sending the lease break notification to the first client,wherein the lease break notification breaks the first lease, and whereinthe lease break notification includes the first access level for thesecond lease.
 16. The one or more computer storage media of claim 15,wherein the lease access level is comprised of: read access, writeaccess, and read and write access.
 17. The one or more computer storagemedia of claim 15, wherein upon granting the first lease, the serversends the first client file data and metadata corresponding to the file.18. The one or more computer storage media of claim 15, wherein thelease break notification includes the first lease identifier.
 19. Thecomputer storage media of claim 15, wherein collapsing further comprisescomparing the first client to a list of clients in an access controllist.
 20. The computer storage media of claim 9 further comprisingconfirming that the first client is allowed access to the file at thesecond access level.